关于网传B站拿用户CPU当挖矿分流工具…-倦意博客

在某乎看到这么一个帖子：

大概内容是网传B站用用户CPU挖矿。󠄐󠄹󠅀󠄪󠄡󠄠󠄣󠄞󠄢󠄡󠄡󠄞󠄧󠄡󠄞󠄢󠄩󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄤󠄦󠄩󠄦󠄦󠄤󠄦󠄡󠄬󠅒󠅢󠄟󠄮󠇕󠅰󠆖󠇖󠅴󠅿󠇕󠅽󠆊󠇕󠆞󠆒󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

我也下了一个uBlock来看看到底拦截了什么：

确实如上述用户所说：在一分钟内拦截了360+条访问󠄐󠄹󠅀󠄪󠄡󠄠󠄣󠄞󠄢󠄡󠄡󠄞󠄧󠄡󠄞󠄢󠄩󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄤󠄦󠄩󠄦󠄦󠄤󠄦󠄡󠄬󠅒󠅢󠄟󠄮󠇕󠅰󠆖󠇖󠅴󠅿󠇕󠅽󠆊󠇕󠆞󠆒󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

我对拦截的链接提交给DeepSeek进行分析，结果如下：

根据提供的链接和请求载荷分析，这是一个B站（哔哩哔哩）的数据上报接口，主要用于收集用户行为数据和实验性功能（A/B测试）的日志信息。以下是详细分析：

1. 链接功能

域名：data.bilibili.com 是B站专门用于数据收集的子域名。
路径：/v2/log/web 表明这是第二代Web端日志上报接口。
参数：
content_type=pbrequest：数据使用Protocol Buffers（一种高效的数据序列化格式）编码。
logid=021436：日志类型的唯一标识符（可能对应特定事件类型）。
disable_compression=true：禁用压缩，可能是为了调试或降低服务器开销。

2. 请求载荷解析

载荷是Protocol Buffers编码的二进制数据，解码后可能包含以下内容（根据字段名推测）：

用户行为跟踪：
promotion_card.content.show：推广卡片内容的展示事件。
view_later_btn.0.show：“稍后再看”按钮的展示事件。
设备与上下文信息：
设备ID（如B2651ACD-DDA2-E89F-6285-52874672DBCC）、分辨率（1920*1080）、浏览器信息等。
页面URL（https://www.bilibili.com/）和客户端版本（1.1.4）。
A/B测试相关：
ab_version 和 ab_split_num 字段表明用户被分配到不同的实验组（如home_version: V8）。
灰度发布（GreyResult）相关字段，如版本ID（109884）和灰度策略（gray）。
广告与运营内容：
operate_material_id、operate_location 等字段可能关联运营位（如banner广告）的展示。

3. 返回404的可能原因

正常现象：此类日志接口通常设计为“上报即丢弃”，服务器可能不返回实际内容（HTTP 200或204更常见，但404也可能是预期行为）。
链接失效：旧版接口已停用，但客户端仍尝试上报。
权限问题：接口可能需要特定权限或头部信息。

4. 数据用途推测

B站可能通过这些数据：

优化用户体验：分析按钮/卡片的曝光率，调整页面布局。
A/B测试：验证新功能（如V8首页版本）的效果。
广告投放：跟踪运营内容的展示次数和位置。
灰度发布：控制新功能对特定用户群体的可见性。

5. 用户隐私提示

虽然数据经过匿名化（如设备ID可能脱敏），但仍可能包含敏感信息（如IP、分辨率）。B站的隐私政策应涵盖此类数据收集行为。

如需进一步验证，建议通过浏览器开发者工具抓包，观察实际请求/响应流程。󠄐󠄹󠅀󠄪󠄡󠄠󠄣󠄞󠄢󠄡󠄡󠄞󠄧󠄡󠄞󠄢󠄩󠄬󠅒󠅢󠄟󠄮󠄐󠅅󠄹󠄴󠄪󠄾󠅟󠅤󠄐󠄼󠅟󠅗󠅙󠅞󠄬󠅒󠅢󠄟󠄮󠅄󠅙󠅝󠅕󠄪󠄡󠄧󠄤󠄦󠄩󠄦󠄦󠄤󠄦󠄡󠄬󠅒󠅢󠄟󠄮󠇕󠅰󠆖󠇖󠅴󠅿󠇕󠅽󠆊󠇕󠆞󠆒󠄐󠇗󠅹󠅸󠇖󠆍󠅳󠇖󠅹󠅰󠇖󠆌󠅹󠄬󠅒󠅢󠄟󠄮

第二种链接进行分析：

这个链接 https://cm.bilibili.com/cm/api/fees/pc 是B站（哔哩哔哩）的一个 广告/内容曝光计费（Cost-per-Mille, CPM）上报接口，主要用于记录广告或推荐内容的展示事件（如曝光、点击等），以便进行广告结算或内容推荐效果分析。以下是详细解析：

1. 链接功能

域名：cm.bilibili.com
cm 可能代表 “Content Management”（内容管理） 或 “Cost-per-Mille”（千次展示成本），表明这是一个与广告/内容计费相关的服务。
路径：/cm/api/fees/pc
fees 暗示与计费（如广告分成）相关，pc 表示PC端的数据上报。

2. 载荷解析（关键字段说明）

请求的JSON载荷包含一个 uploads 数组，记录了一次内容曝光事件：

{
  "uploads": [{
    "src_id": 4699,          // 内容源ID（如广告位ID或内容分类）
    "track_id": "",          // 追踪ID（通常用于广告归因，此处为空）
    "is_ad": 0,             // 标记是否为广告（0=非广告，1=广告）
    "area": 1,              // 展示区域（1可能代表首页或其他固定位置）
    "event": "strict_show", // 事件类型（严格曝光，即确保用户真实看到）
    "is_visible": 1,        // 是否可见（1=可见，0=不可见）
    "idx": 5,               // 内容在列表中的位置（第5个）
    "mid": "89407496",      // 用户UID（匿名化处理后的用户ID）
    "ts": 1746722086819,    // 事件触发时间戳（精确到毫秒）
    "resource_id": 4694,    // 资源ID（具体展示的内容或广告ID）
    "load_ts": 1746722064988, // 内容加载时间戳
    "id": 1677664,          // 唯一事件ID
    "request_id": "1746722065732q172a27a111a95q3725" // 请求唯一标识
  }]
}

3. 上报逻辑分析

事件类型：strict_show
表示这是一个 严格的曝光事件（需满足一定可见性条件，如50%像素在视窗内持续一定时间）。
非广告内容：is_ad: 0
上报的内容可能是B站自身的推荐内容（如视频、专栏等），而非第三方广告。B站可能通过此类数据优化推荐算法。
计费与分成：
如果是合作内容（如UP主推广视频），B站可能根据曝光量计算分成费用。
性能监控：
load_ts 和 ts 的时间差可用于计算内容从加载到展示的耗时，优化用户体验。

4. 返回错误分析

错误信息：{"code":-400,"message":"Request method 'GET' not supported"}
该接口要求使用 POST方法 提交数据，但实际可能被误发为GET请求（或测试时未正确构造请求）。
正常情况应返回HTTP 200或204（无内容），错误可能是调试阶段的误触。

5. 与其他接口的关联

与 data.bilibili.com 的区别：
data.bilibili.com 侧重用户行为日志（如按钮点击、页面加载），而 cm.bilibili.com 专注 内容曝光与计费，可能涉及商业化结算。
与广告系统的联系：
如果 is_ad=1，数据可能同步到B站的广告系统（如ADX或DSP），用于广告主结算。